第2章 パッケージ原則
パッケージングに関する6つの原則
プロダクト内で複数のコードをどのようにまとめて再利用するか （2章扉）
アーキテクチャのレイヤー分け、レイヤー内での部品分け、単にフォルダ分けしただけのコード、それらすべての、複数のコードの集まりをパッケージと考えましょう。 (Kindle 版 p.66 2-1)
感想
OSSでコードを公開する上で参考にできそう！
ひとつのパッケージの凝集度に着目する原則 3つ
REP: Reuse-Release Equivalent Principle（再利用・リリース等価の原則）
リリースされたものだけ再利用、再利用したければリリース
ドメインモデルがもっとも再利用性が高い
アプリケーションの中のいろんなところで利用できる
リリースとは作者からのいったんの手離れ
mainブランチへのマージもリリース
再利用の単位を適切に分け、オープンソースの公開ライブラリのように、リリースと再利用が一致するまとまりの粒度を設計しましょう。(Kindle 版 p.67 2-1)
CRPとCCPで適切な再利用単位を見極める
CRP: Common Reuse Principle（全再利用の原則）
ひとつのパッケージ(またはバージョン)に起きたコード変更は、すべて利用するか、まったく利用しないかのどちらかを選ぶしかありません。(Kindle 版 p.68 2-2)
気づき：バージョンを上げるか、そのバージョンで継続して使うか、私たちは選択している！
ひとつのパッケージに多くを含みすぎてはならない
分けるべきものを分けよ (2-3 CCPと対比して)
責務・責任
与えられた主目的をこなす能力 (Kindle 版 p.69 2-2)
👉 ミノ駆動本
「責務がひとつの概念で収まる」
キーボードという概念で例（概念に対応するパッケージの例でもある）
（主目的：PCへの文字入力）
ちょっと分けすぎで十分
後で分けてあるものを混ぜるのは簡単ですが、混ざっているものを分け直すのは非常に困難 (Kindle 版 p.71 2-2)
CCP: Common Closure Principle（閉鎖性共通の原則）
ひとつの変更が必要なとき、できるかぎりひとつのパッケージだけを交換すれば済む形にしなさい (Kindle 版 p.71 2-3)
閉じている
パッケージ自身の責務セットがほどよいサイズで自己完結している
例：キーボード（接続がUSBかBluetoothかしか気にしない）
キーボードだけを交換すれば済む
利用者から見てとても扱いやすくなる
あちこち変更とは真逆の状態
修正が他の部分のコードに波及しない
凝集度・結合度
全再利用の原則（CRP）と閉鎖性共通の原則（CCP）は「分けるべき」と「まとめるべき」の両側から、責務とパッケージがちょうど1：1になるのが良いということを説明しています。(Kindle 版 p.74 2-3)
凝集度と疎結合性が表裏一体
関係性の強いものが集まるようになるほど、集合間は疎結合
イメージ：ギュッと詰まった2つの円の間に細いつながりがある
関係の強いものが分散しているのが密結合（よくない状態）
複数のパッケージの関係に関する原則 3つ
ADP: Acyclic Dependencies Principle（非循環依存関係の原則）
パッケージの依存が循環してはならない (Kindle 版 p.75 2-4)
あくまでパッケージ間の循環依存の話
循環依存＝一つの大きなパッケージに複数の責務を混ぜ込んだのと同じ
まずさは分かっても、意図せずに発生してしまう
依存の循環は、両者を一つのパッケージに閉じ込める
例：java.lang
パッケージとは、こうした密な結合を閉じ込めるもの (Kindle 版 p.76 2-4)
SDP: Stable Dependencies Principle（安定依存の原則）
パッケージの依存は常により安定したパッケージに向く (Kindle 版 p.77 2-5)
真理を語っている（常に向く）
不安定に依存するとそれ以上の安定はない
安定＝stable＝変更の起きにくさ
依存パッケージが変わるのは、自身に変更を加えたのと同じ意味 (Kindle 版 p.78 2-5)
クリーンアーキテクチャ、円の中心（アプリケーションの本質）に向く
SAP: Stable Abstractions Principle（安定度・抽象度等価の原則）
安定度が高いパッケージであるためには抽象度が高くなければならず、安定度の低いパッケージでよい場合は抽象度が低くてもよい (Kindle 版 p.79 2-6)
抽象（4点）
実装詳細を自身から排除（抽象クラスやインターフェース）
詳細を持たないものだけに依存するロジック
「具体的な手順は後で作る予定」
汎用概念とその操作（時刻や配列）
サードパーティのユーティリティライブラリ
プログラミング言語そのもの
何にでもなれる（プログラミング言語で表現できる）
👉クリーンアーキテクチャの4つの同心円の説明になっている
クリーンアーキテクチャについての補足（2-7）
インフラストラクチャの外側
クリーンアーキテクチャで作るアプリケーションではインフラストラクチャが一番不安定
ドメインモデルとは別の価値観の安定抽象がある（外部のソフトウェア。データベースやフレームワーク）
インフラストラクチャは、内部にあるインターフェースアダプターのモデルと、外部にある別の価値観の安定抽象との、両方に依存します。(Kindle 版 p.84 2-7)